Introduction

The security pattern template is provided as a guide to the structure of the security patterns.

Feel free to include additional sections as required. There’s no perfect answer to what should or shouldn’t be included in the template.

You may wish to add traceability to additional design artifacts or customise the layout to match any design pattern templates that you’ve used previously. Or you may wish to change to a different threat modelling techniques that you’re more comfortable or familiar with.

Fundamentally, the methodology provided for developing your own security patterns should allow you to adapt and modify the example use cases to meet your specific organisational needs

Just remember to maintain the original intent that makes up these security pattern

1. Standardise on the taxonomy to allow traceability
2. Ensure the pattern remains abstracted from the technology to allow reusability
3. Maintain traceability of the security control objectives to the problem being addressed.

Template Style Guide and Format

Black: Content that forms the security pattern template.

Italics: Description of the content to be populated within the template. This can be removed when writing the pattern.

Security Pattern - Title

Overview

The following security pattern describes

Include a brief abstract summary to the pattern and background to the problem (in a few sentences).

Include the purpose and intent of the pattern, but does not go into implementation details.

Include a list of any specific considerations that should be taken into account when addressing security challenges associated to the problem statement.

Scope

The scope of this document is for addressing the security threats that relate to

Out of Scope 

Dependencies

Constraints

Assumptions

Assets at Risk

The following section provides a list of assets affected by the problem statement:

Describe the different assets that are affected within the defined problem space and a brief description.

The following assets are also referenced within the pattern but not in scope

This section is useful for referencing assets that were reviewed but not considered in-scope. This helps provide completeness in your thinking and or allows you to reference other security patterns that may cover those assets

Threat Model

The following section provides a list of threats within the problem statement:

This section is used to map the Threat Event as defined under the Threat Taxonomy. Include own custom descriptions, relevant to the problem statement and assets affected. Consider the different adversarial or non-adversarial sources associated to those threats.

Target State Solution

Summary 

The target state solution evaluates the following design requirements to provide the expected target state solution and design principles.

Design Requirements  

The target state solution is required to meet the following requirements, as referenced under Dependences, Assumption and Constraints.

List out any requirements from external compliance or regulatory bodies that are being addressed within this pattern. Please Note: Listing specific traceability of regulatory requirements to security control objectives should be provided in the Appendix.

List out the principles, and the implications that these have to design of the solution in context of the problem being addressed and in scope assets

List out any constraints and restrictions that this may apply to the design.

Solution Overview

Provides a general description and context of the solution and how the problem space is being addressed). Includes a description with text and/or graphics of the intended solution across identified assets.

Design Principles  

The following design principles are applied under this pattern, based on the requirements.

Provides a list of design principles, summarised from the design requirements and in context of the overall solution. Use the following optional sections Actors, Locations and or Sequencing where relevant.

• Describe principle #1
• Describe principle #2
• Describe principle #n

Actors

List the actors involved in this pattern.

This section should reference any roles or actors that maybe involved. For Example, this could be users involved in design, build, testing, deployment, administration, monitoring or usage of those assets. Please Note: This section should not be confused with intended audience or stakeholders of security patterns.

Locations

This pattern is applied to any locations for assets being utilised

List out any implications to location of assets within different within trust levels of Domain / Zone model or different geographic locations. For Example, this could be locations that influence design for Internal, Partner or Public Facing assets.

Sequencing

The pattern is designed within the following sequences

Any Process and Procedures that should be considered. For Example, this pattern covered all delivery phases for Design > Build > Test > Operate.

The following provides a mapping of security threats to affected assets and the security control objectives required to mitigate them (further detailed in subsequent security pattern logical designs).  

Recommend to utilise a separate spreadsheet for performing this mapping and then copy into document

Security Pattern

Pattern View: Title of Asset Group

Include any relevant diagram(s) for the pattern.

 Control list: Title of Asset

Appendix A - References

• Link
• Link